F.A.F.O. is not just an internet meme, it's also a way of approaching problems in the real world and a suggestion on how to make classroom and programming environments more real and more meaningful to those who participate.
In regular parlance, when FAFO is invoked, it's usually with a negative idea, that there are consequences, and inevitable consequences, that happen when a person start Farting Around in their lives. Adopting Fart Around and Find Out as an intentional idea acknowledges that there will be consequences, and encourages seeking out those consequences so as to better understand both the problem and a potential solution that may work for it.
Research into Maker methods and real-world problem-solving suggest that learners get more benefit and more involvement in their learning when the problems are suited to their own contexts and life situations, especially when compared to textbook problems and scenarios. Real-world problems are less likely to appear in school classrooms or library programming settings, and school and library programs sometimes have space and time constraints that prevent full engagement in trying to solve those real-world problems. Classroom and library programs, however, can encourage tinkering and put sparks in motion, but without further ability to explore scenarios, or support for continued learning and tinkering outside of the library or classroom, the leap from getting someone started to keeping them interested and working on long-term and real-world problems doesn't happen easily. Independent motivation and investment in tools to study and try and enact solutions are often the province, and privilege, of a certain few. We can do better.
The idea of Failing Around and Finding Out is embedded in the scientific method, although it's not necessarily understood or taught that way. When we teach the scientific method, the process seems neat and tidy. We have a hypothesis, we do an experiment, we get results. Most diagrams and explanations of the Method point out the possibility that experimentation may not prove the hypothesis, and that it may be necessary to discard the original hypothesis or modify it in light of the evidence, but it's not usually reported in final papers how much wrong there was before something finally went right, and how much of experimentation in science is about being wrong about something before something finally goes right.
Somewhat tongue-in-cheekily, but if you play the game "PhD 2048," you get a good representation of the amount of time spent and complications produced when trying to create a work worthy of a doctoral degree. It takes the already difficult game of 2048 and adds complications to it related to the life of the researcher.
But more seriously, the Best Practices in Science project at Stanford University maintains a list of journals and blogs that are specifically about publishing high-quality experiments in different disciplines that return results favoring the null hypothesis. That is to say, the experiment happened and nothing new came out of it. They also maintain articles about why scientists shy away from admitting their failures, even if those failures are good science. So many incentives skew toward publishing positive results and papers, that the amount of work that went into finding the things that were not the results is basically hidden and discarded.
Merely giving someone the opportunity to fail does not a learning environment make. Tinkering and making have lowered the cost of failure by encouraging rapid prototyping and sourcing their materials from donations and castoffs, or by investing in things that are expensive, but then usable by the community, so as to take the price of each individual thing down significantly. By emphasizing process over product, even if there is a desired product in mind, makes failure about learning ways that something doesn't work, on the way toward learning what does. And it puts the focus of the exercise on all of the learning that happens along the way, rather than reserving judgment of success based on whether or not the final product functions as intended. The best environments for process-based learning and experimentation, then, come from where it's safe and encouraged to Flop Around and Find Out, with no pressure to produce a working result, except from whatever internal motivation there is for the learner to find a useful, working, or even partially-working solution to their problem.
Classrooms and the pressure of grades sometimes sour attempts at building this environment, but public libraries and library programming is generally offered without this expectation of either a finished product or an evaluative grade. This makes public libraries ideal for this kind of experimentation and process-based learning in whatever programming they offer, whether it's high-tech, low-tech, or just messing around with things to create art.
For example, taking apart known non-working technology just to see what it looks like inside will help people get familiar and comfortable with the tools that they'll need, as well as giving them a subtle idea, or an obvious idea, about how difficult some technology is to disassemble and repair, and how easy some other types might be. Plus, having gone at something with devices that you can make mistakes on, if the opportunity or requirement comes up where they have to unassemble something of their own to try and fix it, they'll have had practice with how the process goes and what things to watch out for. Creating art of just about any form, so long as it focuses on the process instead of the product, gives people more familiarity with the tools and their own creative processes. Making sure there's enough time and materials on hand to work through the processes of Fiddling Around and getting to the Finding Out phase, is the important part.